Dify Needs a Governance Layer — and That is a Feature, Not a Bug

[kuangmi-bit]

By DeepArchi | July 18, 2026

---

Dify maintainers have made something clear over the past four months: they are not building agent governance. Three issues — from a security auditor, from Microsoft, and from an independent developer — were all closed as not_planned. #34021, #34100, #34687.

At first glance, this looks like a gap. A platform with 149K stars, 280 enterprise customers including Maersk and Novartis — but no pre-execution policy enforcement? No delegation scoping? No signed audit receipts?

This is not a gap. This is product discipline.

Dify is the build layer. Governance is a different layer entirely. And the community is already proving it needs both.

---

The Signal in the Noise

Between March and July 2026, four distinct community members raised governance concerns:

• @lirik173, security auditor: Pre-execution policy hook between LLM tool selection and execution → not_planned
• @imran-siddique, Microsoft: Integration of Microsoft Agent Governance Toolkit (6,100+ tests) → not_planned
• @aeoess: Ed25519-signed audit receipts per tool call → not_planned
• @chengduman, Zhongpu Consulting: Multi-tenant isolation, SSO, usage metering — had to hand-write FastAPI middleware for 3 enterprise clients

The pattern is unmistakable: enterprises are deploying Dify agents into production, hitting the same wall. Not "how do I build an agent?" — but "how do I prove this agent did not do something it should not have?"

---

What We Built

Three open-source Dify-native plugins (all MIT):

1. Trust Tier (github.com/deeparchi-ai/maea-trust-tier) — Four-tier permission model, delegation limits, rate limiting, parameter validation
2. A2A Bridge (github.com/deeparchi-ai/maea-a2a-bridge) — Agent-to-agent messaging, task delegation with timeout/budget/fallback, agent discovery
3. Tenant Gateway (github.com/deeparchi-ai/maea-tenant-gateway) — Multi-tenant isolation, JWT/OIDC, Prometheus metrics

Full architecture doc: github.com/deeparchi-ai/MAEA-Framework

---

Why This Matters Now

• 88% of enterprises report agent security incidents
• Only 14.4% of agents receive full security approval before going live
• EU AI Act §12 requires record-keeping. DORA §11 requires independent audit verification.

Feedback welcome — especially from anyone running Dify agents in production.

[taohui]

This is a great distinction. I think there’s another layer worth separating as well: model governance.

Agent governance answers questions like:

• What can an agent do?
• Which tools can it call?
• Who can it delegate tasks to?

Model governance answers a different set of questions:

• Which models can the agent access?
• Who is allowed to use them?
• How are rate limits and quotas enforced?
• How should requests be routed or failed over across providers?
• How do you control and observe model usage and cost?

In that sense, I see Agent Governance and Model Governance as complementary layers rather than competing solutions.

This is the problem we’re working on with ModelPointer, an open-source model gateway for access control, rate limiting, routing, fallback, and usage observability across multiple LLM providers.

Dify can remain the build layer, while a model gateway can sit underneath as the model governance layer.