Security Boundary and Runtime Hardening
Highlights
- Arbitrary Python execution tools are no longer registered by default.
- Added the bounded
safe_expressiontool and publicevaluate_safe_expression()API for arithmetic and data-only expressions. - Added explicit
enable_unsafe_python=Trueopt-in for legacy Python execution tools. - Added fail-closed
SandboxProvidergating and theLA-SANDBOXerror code for model tool calls. - Added trace policy events for blocked execution-capable tool calls.
- Updated English and Chinese documentation, security guidance, tools documentation, and roadmap.
Compatibility
Existing applications that directly import and call execute_python_code, execute_python_file, or execute_python_code_stream retain those APIs. Applications relying on automatic registration must explicitly opt in with enable_unsafe_python=True and provide a real isolated SandboxProvider.
Security
The Python executor remains a controlled subprocess, not a security sandbox. Do not expose it to untrusted users without OS-level isolation, resource limits, filesystem/network restrictions, and an explicit policy/approval layer.
Verification
- 275 tests passed, 1 skipped
- Python 3.10, 3.11, 3.12, and 3.13 CI passed
compileallandgit diff --checkpassed