1. Security design
- Local controller: the desktop backend binds to loopback and authenticates local UI requests with a per-launch token.
- Explicit project scope: Supervised tools constrain project access and request approval before acting.
- Separate elevated session: administrator commands require Windows approval and run through a separate helper.
- Reviewable evidence: file changes, checks, previews, and eligible checkpoints are shown for review.
- Signed updates: update metadata and downloaded packages are checked before execution.
- Credential care: connector credentials are kept out of browser-visible application state and protected locally where supported.
- Website hardening: HTTPS, HSTS, a restrictive Content Security Policy, frame denial, referrer limits, and browser permission limits are configured.
2. Important boundaries
ForgeDesk permission controls are not an operating-system sandbox. Commands run with the authority of the Windows account, and an explicitly enabled administrator session can do more. Full access intentionally relaxes ordinary project restrictions. A model can still make a harmful mistake, so review authority and maintain backups.
Optional remote models, web pages, Gmail, MCP servers, GitHub, browser sessions, and other connected services are separate security boundaries. Only connect services you trust and review what a task is allowed to send.
3. Report a vulnerability privately
Email security@forgedesk.dev with:
- the affected version, component, and environment;
- clear reproduction steps or a minimal proof of concept;
- the security impact and any data or permissions involved;
- whether the issue is already public; and
- a safe way to contact you.
Do not include real user data, credentials, or destructive payloads. The security mailbox and an out-of-band backup contact must be established before public distribution. Machine-readable contact information is available at /.well-known/security.txt.
4. Good-faith research guidelines
When acting in good faith, use your own systems and accounts, minimize access, stop after demonstrating impact, preserve evidence, and give ForgeDesk reasonable time to investigate before public disclosure. Do not disrupt service, access another person’s data, use social engineering, demand payment as a condition of silence, or violate law.
ForgeDesk intends not to initiate legal action for research that follows these guidelines, but this statement cannot authorize testing of third-party services or waive rights held by others.
5. Response process
ForgeDesk aims to acknowledge a credible report within five business days, assess severity, coordinate remediation and disclosure, and credit the reporter if requested. Timelines depend on complexity and exploitation risk. Critical actively exploited issues may require rapid protective changes before full disclosure.
6. Updates, incidents, and support
Installed copies check for signed updates periodically and can install them when idle. Keep ForgeDesk, Windows, WebView2, Ollama, connected tools, and models current. A formal support period, vulnerability-management process, software bill of materials workflow, and applicable regulatory incident reporting playbook must be published before broad commercial distribution.