C1 Identity & least privilege
Minimal 0.15 / 1.00
Agents and workflows act with workspace-level provider and tool credentials that any member can configure and that every end user of a published app then uses, with no per-user authorization. Service-to-service calls between the API, the plugin daemon, and the Agent V2 backend authenticate with single static keys, and those calls name the tenant in the request body; the default service credentials are also not locked down. The Agent V2 sandbox's own callback token is properly scoped by a signed execution context, but the sandbox can also reach the agent backend's control plane.
C2 Approval gates
Minimal 0.00 / 1.00
No tool call is gated by a human by default. The classic agent runner, the workflow tool node, and the Agent V2 runtime all execute model-chosen tool calls directly, including the Agent V2 shell, which is enabled by default and runs arbitrary scripts with internet access. Workflows offer a Human Input node and Agent V2 offers an ask-human tool, but the first is a step a builder may place in a workflow and the second is a tool the model decides whether to call; neither gates the agent's actions. Consequential actions (third-party write APIs, outbound HTTP, shell) happen without a person seeing them.
C3 Tool & action scoping
Minimal 0.45 / 1.00
Tool arguments are cast to their declared types, and outbound HTTP from OpenAPI tools, MCP clients, and the HTTP node goes through a Squid proxy that blocks private and metadata addresses on every hop, including redirects. But the toolset is general by design: an arbitrary-URL HTTP node, custom OpenAPI tools against any host, and an Agent V2 shell that takes raw scripts. Classic agent apps only receive tools the builder selected, while Agent V2 adds the shell by default. A misused tool can reach any public host with the workspace's credentials.
C4 Code-execution isolation
Moderate 0.50 / 1.00
Model-driven code runs outside the API process: workflow code and template nodes go to the separate dify-sandbox service, and the Agent V2 shell runs in a dedicated non-root container with Landlock filesystem rules per job. That container is shared by every workspace on the deployment, its Landlock layer silently falls back to no isolation on unsupported kernels, and its policy configuration is not integrity-protected. Inside, the shell holds the agent's secret environment variables and a callback token, has public internet egress, and has a direct network route to the agent backend. An opt-in E2B backend moves the shell to a remote sandbox service.
C5 Untrusted input blast radius
Minimal 0.20 / 1.00
Nothing structurally limits a hijacked agent. Untrusted content arrives from public web-app users, crawled web pages, uploaded documents, tool and MCP results, and shell output, and enters the model's context with no provenance marking beyond plain output tags on shell results. The same session can hold workspace secrets in the shell environment and has open egress through the shell and HTTP tools. A successful injection can therefore leak data and take irreversible actions with no human involved.
C6 Memory, context & configuration integrity
Minimal 0.25 / 1.00
Conversation history is scoped to a conversation and knowledge-base retrieval is filtered by workspace in queries. Agent V2 lets the model itself push persistent changes to its own agent configuration (skills, notes, files, and environment variables) through the sandbox CLI, limited to build-draft sessions by a signed context; those changes load into later runs and reach end users once a builder publishes. Knowledge bases filled from crawled websites or uploaded documents are retrieved for every user of an app with no provenance or review step.
C7 Third-party extensions
Minimal 0.07 / 1.00
Marketplace plugins are installed by pinned unique identifiers and the plugin daemon ships with signature verification forced on, but any workspace member may install plugins by default and patch updates are applied automatically without re-approval. Plugins run inside the plugin daemon container, which holds database and storage credentials and an unrestricted network route. Separately, the Agent V2 shell prompt tells the model to install whatever Python or Node packages and MCP servers it needs, and it does so without asking, inside a sandbox holding the agent's secrets.
C8 Secrets & sensitive-data protection
Minimal 0.20 / 1.00
Stored provider and tool credentials are encrypted at rest with per-tenant RSA keys and masked in console responses. But default service credentials are not locked down, the Agent V2 shell receives configured secret values as environment variables while the prompt tells the model they are there, and only the callback token is redacted from shell output unless the operator adds patterns. Anonymous, content-free usage telemetry is on by default.
C9 Audit & traceability
Moderate 0.63 / 1.00
Dify records every tool call in the database: classic agent thoughts store the tool, its input, and its observation; Agent V2 tool calls are relayed back and stored the same way; workflow node executions are persisted by default; and Human Input form submissions are recorded. Records are written by the API server, which the sandboxed shell cannot reach. The record is not tamper-evident, actor attribution is partial (classic agent thoughts are always stamped as account-created), and there is no correlation chain across nested workflows.
C10 Limits & kill switch
Minimal 0.45 / 1.00
Classic agents are capped at 99 iterations, workflows at 500 steps and one hour, and Agent V2 runs at 500 model requests and one hour, with per-call timeouts for the code sandbox and plugins. There is no token or cost cap, per-app concurrency is unlimited by default, and stopping a run sets a flag the loop checks between steps. Nested workflows called as tools get their own budgets, bounded only by a call depth of five.