Critical Security Flaw in PraisonAI: Default Sandbox Fails to Enforce Code Execution Restrictions
Key Takeaways
- ▸SecurityPolicy restrictions are completely unenforced in PraisonAI's default Subprocess Sandbox backend—blocking commands, paths, imports, and subprocess creation have no effect
- ▸Critical deployments using the recommended strict() configuration receive zero protection against arbitrary command execution, sensitive file access, and destructive operations
- ▸Only allow_network and max_output_size are actually implemented in the Subprocess Sandbox; six other security policy fields are documented but non-functional
Summary
PraisonAI, an open-source Python framework for building AI agents, contains a critical security vulnerability in its default Subprocess Sandbox backend. The framework's SecurityPolicy class defines multiple restrictions for untrusted code execution—including blocking dangerous commands, restricting file access, limiting subprocess creation, and controlling imports—but none of these policies are actually enforced by the default sandbox backend.
Researcher LHMisme discovered that while SecurityPolicy includes documented fields like allow_subprocess, blocked_commands, blocked_paths, and blocked_imports, the Subprocess Sandbox implementation completely ignores these restrictions. Proof-of-concept testing confirms that restricted operations execute without impediment: subprocess commands run despite allow_subprocess=False, sensitive files like /etc/passwd can be read despite being explicitly blocked, and dangerous commands like rm -rf execute successfully despite being in the blocked list.
The vulnerability is particularly severe because it affects deployments using PraisonAI's recommended strict() configuration, which is specifically designed for running untrusted code. Only two security parameters—allow_network and max_output_size—are actually enforced in the Subprocess Sandbox, while the remaining fields exist as fully-documented configuration with no corresponding implementation. Since Subprocess Sandbox requires no additional dependencies and is the default backend, this vulnerability likely impacts many real-world deployments.
The root cause stems from incomplete implementation: SecurityPolicy was designed as a backend-agnostic configuration surface, but developers never wired the majority of its security constraints into the default Subprocess Sandbox backend. Remediation options include adding enforcement code to the Subprocess Sandbox or defaulting to native OS-level sandboxing (Landlock/Seatbelt) for untrusted code execution.
- Vulnerability affects potentially widespread deployments since Subprocess Sandbox is the default backend requiring no additional dependencies
Editorial Opinion
This is a high-severity security regression disguised as fully-implemented functionality. The presence of well-documented SecurityPolicy fields and an explicitly-named strict() method creates a false sense of security for developers deploying untrusted AI agent code—arguably more dangerous than no sandbox at all. Immediate remediation is critical, and PraisonAI should consider raising an exception when strict() is invoked against non-enforcing backends to prevent silent failures.



