Dify
0.12.0 (commit 625aace)Platform combining visual LLM orchestration, RAG pipelines, and agent tools.
This evaluation reflects architectural observation and engineering analysis conducted strictly against Dify 0.12.0 (commit 625aace) based on its default framework mechanics. It does not represent an ongoing certification of current upstream releases or an empirical benchmark of your specific deployment. Operational safety in production depends strictly on your implementation of external sandboxes, network egress boundaries, and state constraints.
Review protocol v1.1; revalidate by December 30, 2026. Disclosure status: not applicable — no private vulnerability report opened for these public architecture observations.
Evidence levels: A = reproducible observation; B = version-linked documentation or source; C = insufficient or out-of-scope evidence.
Deployment Evidence & Observation Scope
A separate code sandbox and workflow execution ceilings provide bounded controls, while tool permissions, prompt trust, credentials, and recovery of external writes remain deployment responsibilities.
5-Dimension Architecture & Control Boundaries
Code nodes call a separate sandbox service on an internal network, but sandbox networking is enabled through an SSRF proxy by default and other workflow tools are outside this code-only boundary.
The self-hosted configuration sets workflow-wide step and time ceilings, and agent loops are capped in the reviewed source. These are not mandatory per-node rate limits.
Moderation hooks are configurable, but no default control establishes that retrieved documents or tool output are safe instructions for downstream models.
Workflow and node execution state is recorded, but the reviewed source does not establish automatic rollback of writes already committed to external systems.
Workflow runs retain status, step, timing, and token fields, with optional trace integrations. Retention, redaction, access, and external audit export depend on deployment configuration.
Recommended Enterprise Guardrails & Pre-Deployment Controls
- Replace default sandbox and service credentials before exposing a self-hosted deployment
- Disable sandbox network access unless required; otherwise constrain the SSRF proxy and outbound destinations
- Scope every external tool credential independently and require approval for consequential writes
- Add idempotency keys and compensating actions for workflows that mutate external systems
Overview
Dify 0.12.0 combines visual workflows, agent loops, RAG, external tools, and a separate code-execution service. The tagged source exposes useful execution ceilings and records workflow state, but the sandbox applies to code nodes rather than every integration, and it does not make retrieved or tool-produced content trustworthy.
Scope of Review & Version Baseline
- Repository: langgenius/dify.
- Reviewed Version:
0.12.0(Commit625aace). - License Boundary: The tagged LICENSE is based on Apache-2.0 with additional conditions, including restrictions for some multi-tenant and frontend uses; it is not represented here as plain Apache-2.0.
- Target Execution Model: Self-hosted Docker Compose workflows using code, model, retrieval, HTTP, and tool nodes.
- Primary Evidence Sources: Tagged Docker Compose configuration, agent runners, workflow engine, and workflow persistence models.
- Out of Scope: Dify Cloud controls, runtime penetration testing, the independently versioned sandbox implementation, plugins, and later 1.x releases.
Observed Controls & Code Evidence
- Separate Code Sandbox Service:
The default Compose topology routes code execution to
dify-sandbox:0.2.10on an internal network. Network access is enabled by default through an SSRF proxy, and the repository supplies placeholder service credentials that operators are instructed to replace. - Workflow and Agent Ceilings: The Compose configuration defaults to 500 workflow steps and 1,200 seconds, while the reviewed agent runners cap configured iterations at five plus their terminal pass. These limits bound further execution but do not reverse completed side effects.
- Recorded Workflow State: Workflow persistence includes status, elapsed time, total steps, token counts, inputs, outputs, and error fields. Optional trace integrations exist, but deployment owners control retention, redaction, and access.
Unverified Assumptions & Deployment Dependencies
- Tool and Credential Isolation: The code sandbox does not automatically isolate HTTP nodes, model providers, retrieval services, or external tools. Their credentials and permissions must be scoped separately.
- Indirect Prompt-Injection Resistance: Moderation can be configured, but no deterministic adversarial fixture was run and source inspection does not establish a default trust boundary between retrieved content and tool instructions.
- External Transaction Recovery: A failed later node does not prove that an earlier CRM, database, or API write is automatically rolled back. Idempotency and compensation remain application responsibilities.
Deployment Evidence & Observation Summary
Dify 0.12.0 provides a distinct code-execution service, workflow-level ceilings, bounded agent iteration, and persisted run records. Production use still requires credential replacement, outbound-network policy, per-tool authorization, untrusted-content handling, and recovery design for external writes.
Notice: This source-based profile is limited to Dify 0.12.0 and its repository configuration. It does not certify the sandbox image, Dify Cloud, plugins, later releases, or a specific deployment.
Deploying Dify in your enterprise stack?
Generic evaluations can only evaluate default configurations. BartsAI provides custom Launch Gate reviews assessing your specific tool permissions, private database connections, and corporate release thresholds.