Security Concerns

The origin of ragflow is Chinese. Infiniflow is a Chinese company. It was open-sourced in 2024.

Chinese origin of RAGFlow is not a material security concern in practice — the project is one of the technically strongest deep-document-understanding RAG engines available right now.For organizations that must comply with very strict procurement rules, national security guidelines, or have board-level “no Chinese tech” policies → yes, it’s frequently considered a blocking factor, even if the technical risk is low.Choose according to your actual risk appetite and compliance requirements — not just origin country.

considerations:

to mitigate risc : → Self-host + build your own Docker image from the official source code → Audit the diff yourself or let your security team do it (very feasible — the codebase is not enormous) → Use only Western/local/open-source LLMs & embedding models → Result: concern level drops to same as any other active open-source project

sandbox:

RAGFlow is an excellent open-source deep-document-understanding + Agent-oriented RAG engine.It contains a very powerful feature: Code component inside Agents. Users can write Python or JavaScript code directly in the workflow/agent → this code can:Process retrieved chunks Call external APIs Do calculations / data cleaning Transform data Call other tools dynamically basically anything Python/JS can do

→ This is extremely powerful, but also extremely dangerous if you let random users (or even semi-trusted internal users) write code.

That’s where RAGFlow Sandbox + gVisor comes in

This can be enabled in “.env”.

User → Agent workflow → Code component (Python/JS)

↓

RAGFlow Sandbox Executor Manager

↓

Spawns short-lived container(s) using
runtime: runsc (gVisor)

↓

Code runs inside very strong syscall sandbox

elasticsearch:

  • xpack.security.enabled: true

  • Transport TLS enabled + working (verification_mode: certificate is ok)

  • HTTP TLS enabled (HTTPS) on all nodes that receive traffic

  • Strong passwords set for all built-in users (elastic, kibana_system, logstash_system, beats_system, apm_system, …)

  • Dedicated roles + users for each service (never use elastic superuser in production apps)

  • Keystore used for all passwords (not plaintext in yml!)

  • Firewall: 9300 only between nodes, 9200 only from trusted sources

  • Regular certificate rotation plan (at least yearly, better automated)

  • Monitoring of certificate expiration

  • Audit logging enabled (at least for authentication/security events)