How Dify Established Runtime Control Over Its MCP Ecosystem

The problem

The company had adopted AI-assisted development faster than its security team could standardize how agents accessed internal systems. Engineering teams had connected agents to GitHub, Jira, internal documentation, cloud management APIs, and database tools. Individual teams maintained their own configurations, permissions, and deployment practices.

The result was not a single catastrophic vulnerability. It was a growing governance gap. Security could identify many of the underlying services, but answering these questions required investigation across multiple teams:

• Which agents could invoke each tool?
• Which MCP servers could access sensitive systems?
• Could a read-oriented agent invoke a write-capable tool?
• What happened when a tool's behavior or description changed?
• Could the company prove that a prohibited action had been denied before execution?

Existing identity and network controls remained important. The missing capability was consistent enforcement of agent actions across the connected tool estate.

The architectural gap

The existing pattern was:

Agent → MCP client → MCP server → underlying system

# Authorization depended on server configuration, application
# permissions, credentials, and per-team implementation choices.

That created inconsistent enforcement across teams. The company needed a common policy decision point that could evaluate covered tool calls independently of the model's interpretation of a tool description.

The attack scenario

During a controlled red-team exercise, the security team introduced a simulated compromised MCP server into an isolated test environment. The server exposed a tool that appeared to retrieve deployment documentation. Its tool description also contained adversarial instructions intended to persuade an engineering agent to invoke a privileged repository operation.

The agent retrieved the tool description, incorporated the instructions into its planning, and attempted to invoke a write-capable tool against a protected repository. The requested operation was syntactically valid. The agent's identity was valid. The underlying repository integration had access to the target.

The issue was not whether the model could recognize the malicious description. It was whether the resulting action was permitted.

What SAILLENT saw

The following is an illustrative enforcement event, not a real production log.

DECISION
DENIED

AGENT
engineering-agent-prod

SERVER
mcp-repository-tools

TOOL
repository.update_branch_protection

TARGET
payments-service / production branch

POLICY
engineering-repository-controls-v8

REASON
Agent role not authorized to modify branch protection

EXECUTION
NOT PERFORMED   # protected operation not forwarded

The request was denied at the configured enforcement boundary. The underlying repository operation was not invoked through this request path.

The control model

The company established policies around agent identity, MCP server, tool identifier, action, target, and risk. Examples included:

• Documentation agents could read approved repositories.
• Coding agents could create branches and pull requests.
• Only designated deployment identities could modify production deployment settings.
• Agents could not change branch protection or grant themselves additional privileges.

The policy did not treat every MCP server as malicious. It treated tool metadata and tool responses as untrusted input, while enforcing explicit authorization rules on covered operations.

What changed

BEFORE
Team-specific configurations, inconsistent tool restrictions,
fragmented evidence.

AFTER
Defined inventory, centralized policy for covered actions,
auditable ALLOW / DENY decisions.

Illustrative results

The 27 denied operations represent a defined test set, not proof that every possible MCP attack was prevented.

The operational outcome

The company moved from treating MCP security primarily as a collection of individual integration decisions to treating agent-to-tool interaction as a governed security boundary. The outcome was not universal visibility into every AI system in the enterprise. It was consistent enforcement and evidence for the MCP interactions included in the deployment scope.

MCP expands what agents can do. Independent authorization determines what they may do.