The yim project takes security seriously. This document outlines our security policy, including supported versions, how to report vulnerabilities, and our disclosure process.

The following versions of yim are currently supported with security updates:

We provide security updates for the latest minor version in each major version series. Users are encouraged to upgrade to the latest version to receive security patches.

If you discover a security vulnerability in yim, please report it to us as soon as possible. We appreciate your efforts to responsibly disclose your findings.

Please do not report security vulnerabilities through public GitHub issues or Gitee issues.

Instead, please report security vulnerabilities via:

📧 Email: dunimd@outlook.com

For general questions and non-security issues, please use:

• Gitee Issues (Primary): https://gitee.com/dunimd/yim/issues
• GitHub Issues (Mirror): https://github.com/mf2023/Yim/issues

Please include the following information in your report:

• Description: A clear and concise description of the vulnerability
• Impact: What kind of vulnerability is it and what impact could it have
• Affected Versions: Which versions of yim are affected
• Steps to Reproduce: Detailed steps to reproduce the vulnerability
• Proof of Concept: If possible, include a proof-of-concept or exploit code (especially for tool injection, prompt injection, or sandbox escape)
• Suggested Fix: If you have suggestions for how to fix the vulnerability
• Your Contact Information: How we can reach you for clarifications (optional)

When you submit a security report, you can expect the following:

1. Acknowledgment: We will acknowledge receipt of your report within 48 hours
2. Initial Assessment: We will provide an initial assessment within 5 business days
3. Investigation: We will investigate the vulnerability and determine its impact
4. Fix Development: If confirmed, we will work on a fix and may reach out for additional information
5. Disclosure: We will coordinate with you on the disclosure timeline

Our target response times are:

yim provides 35 built-in tools that can execute code and access the filesystem. Security measures include:

• bypass: No permission checks (development only)
• dont_ask: Automatically allow all tool calls
• accept_edits: Auto-allow file edits, ask for other actions
• plan: Require approval for all disruptive operations
• auto: Heuristic-based permission decisions via safety classifier
• default: Always ask for user confirmation before executing tools

• Shell command pattern analysis detects potentially harmful operations
• Commands like rm -rf /, dd if=/dev/zero, :(){ :\|:& };: are blocked by default
• Configurable allow/block lists for command patterns

• Optional Docker container sandbox with seccomp profiles
• Restricts system calls available to executed commands
• Isolates file system access within the container

• DNS resolution validation before connection establishment
• CIDR blocklist for private/internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, etc.)
• Prevents Server-Side Request Forgery via web fetch and web search tools

• API keys stored in environment variables or encrypted configuration
• AES-256-GCM encryption for sensitive data at rest
• The crypto.py module provides secure encryption/decryption
• Credentials are never logged or exposed in tool outputs by default

• yim uses a multi-layered system prompt architecture
• Safety classifiers can detect injection attempts
• Tool input validation sanitizes parameters
• The auto classifier uses the LLM itself to evaluate permission requests

• Persistent memory stored as local .md files in memdir
• No default telemetry or data collection
• All data remains local unless explicitly sent to an LLM API
• Memory aging/pruning prevents unbounded data accumulation
• Encryption available for sensitive memory data

• Context isolation enabled in Electron (contextIsolation: true)
• Preload script provides minimal, audited API surface
• Node.js integration disabled in renderer process
• Content Security Policy headers enforced
• Encrypted cookie store for browser automation (AES-256-GCM)

• LSP client communicates only with locally started language servers
• No remote LSP server connections
• Language server processes are managed and terminated by yim

• All indexing is local (no remote code analysis)
• File access limited to the workspace directory
• Sensitive file patterns (.env, *.key, etc.) excluded from indexing

When using yim in your applications:

Regularly update yim and its dependencies to receive security patches:

# Update Python dependencies
pip install --upgrade yim
pip list --outdated

# Update Rust dependencies
cargo update
cargo audit  # Use cargo-audit to check for known vulnerabilities

# Update desktop dependencies
cd desktop
npm audit
npm update

Choose the appropriate tool permission mode for your use case:

# Maximum security - always ask
agent = YmiAgent(..., tool_permission_mode="default")

# Automated with heuristic checks
agent = YmiAgent(..., tool_permission_mode="auto")

# Development only - no checks
agent = YmiAgent(..., tool_permission_mode="bypass")

from yim import YmiAgent

agent = YmiAgent(
    ...,
    sandbox_enabled=True,
    sandbox_image="yim-sandbox:latest",
)

# Use environment variables (recommended)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Or use encrypted config
python -c "from yim import encrypt_config; encrypt_config('config.yaml')"

Tool outputs are validated before being sent back to the LLM. Custom output validation can be added via hooks:

from yim.hooks import YmiHookSystem

hooks = YmiHookSystem()
@hooks.on_post_tool
async def validate_output(event):
    if "sensitive_data" in event.result:
        return {"block": True, "reason": "Output contains sensitive data"}

Enable audit logging for security events:

from yim import YmiAgent

agent = YmiAgent(
    ...,
    log_level="INFO",
    audit_log="audit.log",
)

• Run yim with least privilege (non-root user)
• Use container security best practices when using Docker sandbox
• Implement network segmentation for multi-agent deployments
• Regular security audits of tool configurations

1. Prompt Injection: Like all LLM applications, yim is susceptible to prompt injection attacks. The safety classifier provides mitigation but cannot guarantee complete protection.

2. Tool Output to LLM: Tool execution results are sent to the LLM provider. Avoid including sensitive information in tool outputs when using external LLM APIs.

3. Browser Automation: The browser automation tool (Playwright) runs in the local environment. Ensure proper access controls are in place.

4. Rust Native Extension: The yim._native module provides fast file I/O and shell execution. The sandbox should be enabled when running untrusted commands.

• Review the configurable tool allow/block lists in your deployment
• Implement proper network security (firewalls, VPCs) for multi-agent setups
• Use secrets management systems for API keys (e.g., HashiCorp Vault)
• Enable audit logging for all tool executions
• Consider running the desktop application in a restricted environment

Security updates will be announced through:

• GitHub Security Advisories
• GitHub Releases (with security fix notes)
• CHANGELOG.md (with security-related changes marked)

• We will acknowledge receipt of vulnerability reports within 48 hours
• We will provide regular updates on our progress
• We will credit researchers who responsibly disclose vulnerabilities (unless they prefer to remain anonymous)
• We will not take legal action against researchers who follow this policy

1. Day 0: Vulnerability reported
2. Day 1-2: Acknowledgment and initial assessment
3. Day 3-14: Investigation and fix development
4. Day 15-30: Testing and validation
5. Day 30+: Coordinated disclosure

We aim to disclose vulnerabilities within 90 days of the initial report, or sooner if a fix is available.

We will publicly disclose vulnerabilities after:

• A fix has been developed and tested
• Affected users have had reasonable time to update
• The vulnerability has been assigned a CVE identifier (if applicable)

Review security-related configuration options in:

• YmiSafetyEngine - Permission mode and dangerous command patterns
• YmiSandbox - Docker sandbox configuration (seccomp, memory limits)
• YmiSSRFValidator - SSRF protection settings
• YmiCrypto - Encryption configuration

We welcome third-party security audits. If you are conducting a security audit of yim:

1. Please follow responsible disclosure practices
2. Contact us in advance if you plan to publish findings
3. We appreciate receiving a copy of the audit report

• OWASP Top 10
• OWASP LLM Top 10
• Rust Security Guidelines
• Cargo Audit
• Python Security Best Practices

For security-related inquiries:

• Email: dunimd@outlook.com
• GPG Key: [Available upon request]

For general questions and non-security issues, please use:

• Gitee Issues (Primary): https://gitee.com/dunimd/yim/issues
• GitHub Issues (Mirror): https://github.com/mf2023/Yim/issues
• GitHub Discussions: https://github.com/mf2023/Yim/discussions

We thank the following security researchers who have responsibly disclosed vulnerabilities:

This list will be updated as vulnerabilities are reported and fixed.

Last Updated: 2026-05-31

Version: 1.0