| 1 | # Security Policy |
| 2 | |
| 3 | ## Reporting a vulnerability |
| 4 | |
| 5 | Use the hosting platform's private security-reporting channel to contact the maintainers. Do not open |
| 6 | a public issue for an unpatched vulnerability. Include impact, reproduction steps, and a suggested fix |
| 7 | when possible, without attaching real user data or active credentials. |
| 8 | |
| 9 | ## Safe local operation |
| 10 | |
| 11 | - Never commit `.config.local.json`, `.env` files, access keys, callback secrets, workspaces, or logs. |
| 12 | - Bind the gateway, WebSocket server, and callback server to `127.0.0.1` unless remote access is intentional. |
| 13 | - Configure `channels.director_callback.secret` before exposing callbacks outside the local machine. |
| 14 | - Set `tools.restrictToWorkspace=true` when filesystem tools should remain inside the workspace. |
| 15 | - Keep `tools.exec.enable=false` unless shell execution is required. |
| 16 | - Add trusted download domains explicitly; the default allow-list is empty. |
| 17 | - Use least-privilege, rotating credentials for optional S3-compatible storage. |
| 18 | - Review the privacy policy of every configured model provider before sending sensitive prompts or media. |
| 19 | |
| 20 | If a secret has entered Git history, deleting the current file is not enough. Revoke or rotate the |
| 21 | credential immediately, then clean the repository history according to the project's release process. |
| 22 |