The full Venice Forge security model is maintained in SECURITY.md.

Do not include exploit details, API keys, tokens, or private user data in a public issue.

Use one of these routes:

• GitHub private vulnerability reporting — If enabled, use the Security → Report a Vulnerability workflow on the repository. This keeps the report private until a fix is coordinated and is the preferred channel.
• Issue label routing — If private reporting is not available, open a GitHub issue labeled security and request a private maintainer discussion in the issue body. Do not post exploit details publicly.

The maintainer will triage reports for supported versions and coordinate disclosure before any public details are posted.

Only the latest release tag is actively maintained. Older versions do not receive security patches.

If you encounter unsafe content, safety guard bypasses, or AI-generated material that inappropriately represents minors (CSAM), report it immediately:

1. NCMEC CyberTipline: If the material involves child exploitation, report it directly to the National Center for Missing & Exploited Children (NCMEC).
2. Venice.ai Trust & Safety: Report the incident to Venice.ai through their official support channels at venice.ai/support.
3. Repository Maintainers: Report bypasses of the Venice Forge safety guard using GitHub's private vulnerability reporting feature in this repository.

Venice Forge strictly requires users to be 18 years or older. The application connects to unrestricted AI endpoints that may generate explicit or sensitive content. Due to the inherent risk of producing AI-generated images that may inappropriately represent minors (CSAM), use of this software by minors is strictly prohibited. Users assume all responsibility for the generated content.

All outgoing Venice API requests are screened by a content safety guard (src/shared/safety/childExploitationGuard.ts) before the payload is forwarded. This runs at every enforcement boundary — the renderer transport (veniceClient.ts), Electron IPC handlers, the Express web proxy, and every prompt-sending UI module (ChatModule, ImageModule, BatchModule, SearchScrapeModule). The guard implements advanced features such as cross-sentence context detection and negative_prompt extraction. The proxy operates on a "fail-close" design (returning a 500 status) if the guard encounters any extraction errors. Raw prompt text is never logged by the safety system.

The Jina research provider (r.jina.ai/s.jina.ai) sends requests via direct fetch() outside the Venice transport chain. A renderer-layer guard runs in SearchScrapeModule.tsx (both runAiResearch() and runProfileDiscovery()) before any Jina or research dispatch, ensuring this path is also guarded.

Safety-guard enforcement is verified by scripts/verify-safety-guard.cjs, which checks all enforcement boundaries (veniceClient.ts, handlers.ts, server.ts, SearchScrapeModule.tsx) as a CI gate. Run it with:

npm run verify:safety-guard

A comprehensive safety guard audit was conducted in May–June 2026 covering all request paths, payload extraction coverage, logging/diagnostics behavior, static verification script robustness, and test fixture safety. Findings are tracked in TODO.md under "CSAM Safety Guard Audit (June 2026)".

Maintainer trigger: Update this document whenever the allowed Venice API endpoint list (src/shared/validation.ts) or the safety guard enforcement boundaries change.

When started with --headless, the application runs an Express loopback bridge server (electron/services/bridgeServer.ts). The following safety measures are strictly enforced:

• Loopback-Only Interface: The bridge server binds strictly to the local loopback interface (127.0.0.1). Binding to any public/LAN interface is blocked by default to prevent network-level credential reuse or SSRF attacks.
• Token Authorization: Every request must provide a Bearer token in the Authorization header. If VENICE_BRIDGE_TOKEN is not set in the environment, a cryptographically secure 32-byte hex token is generated at boot and logged to standard output.
• Safety Guard Enforcement: All prompt-carrying requests (e.g. POST /chat/completions, POST /image/generate) are intercepted and checked against the child safety guard in the Main process context. Bypassing the safety filters results in a 451 Blocked by local safety guard response.

The Developer Traffic Inspector logs request/response diagnostics to the renderer store (src/stores/inspector-store.ts).

• Secret Masking: To prevent exposing keys to local logs, the UI, or export functions, all header lists are sanitized. Header keys matching Authorization, Cookie, x-api-key, or names containing key or token are automatically replaced with ******.
• Sandbox Red-Team Mode: The Red-Team Mode switch disables renderer Markdown/HTML formatting to prevent template injection or rendering exploits from unsafe model outputs, and shows the raw text directly alongside local safety audit signals.

External URLs opened via shell.openExternal are validated by electron/utils/urlSecurity.ts: only https: with public routable hostnames is allowed. RFC 1918 and loopback addresses are blocked.

Venice Forge stores API keys using OS-provided encryption where available:

• Windows: safeStorage (DPAPI)
• macOS: safeStorage (Keychain)

Both the Venice API key and the optional Jina API key use the same storage policy and file (secure-prefs.json).

For Windows and macOS, there is no plaintext fallback. The application will refuse to save any API key if OS-level encryption is unavailable. For Linux and other platforms, a plaintext fallback may be permitted if the VENICE_FORGE_ALLOW_PLAINTEXT_KEY_STORAGE=true environment variable is explicitly set in the process environment (e.g., .env for web mode development, or the shell environment for Electron).

• Jina AI: Requests are sent directly to r.jina.ai and s.jina.ai. The Jina API key is redacted from all logs, diagnostics, and exports. A renderer-layer safety guard runs before all Jina dispatch (see Content Safety above).
• Generic HTTP: Disabled by default. When enabled, it routes traffic through a backend proxy to perform DNS resolution and enforce strict SSRF blocklists on the resolved IP. Only allows text/html, text/plain, application/xhtml+xml, and application/json responses.
• All research traffic respects the same endpoint allowlist and safety guard as Venice API calls.

The security model does not protect against the following:

• Unsigned Windows SmartScreen warnings.
• Unsigned macOS Gatekeeper warnings.
• Local malware or debuggers running under the same OS user account.
• Keychain/session compromise if the OS user is compromised.

Clarification: macOS Gatekeeper and quarantine flags are mechanisms for distribution trust and execution prevention. They are not app data encryption mechanisms.

Dependencies are audited with npm audit before each release. To run a manual audit:

npm audit

A clean audit at the moderate level or higher (npm audit --audit-level=moderate) is a release gate requirement.

npm run verify:safety-guard is also a mandatory release and commit security gate — see the Content Safety section above for details.

The repository is scanned by GitHub CodeQL on every push. Findings appear in Security → Code Scanning.

All CodeQL findings in server.ts and the GitHub Actions workflows are either fixed or dismissed with justification. The two defended false positives are annotated at the call site with // nosec:js/<rule-id> plus an inline justification:

• server.ts:387 — js/resource-exhaustion: setTimeout duration is Math.min(timeoutMs, 180000) || 30000 (3-minute max). CodeQL does not see the clamp because it lives inside a conditional expression.
• server.ts:393 — js/request-forgery: The parsed URL is validated against an allowlist of ["r.jina.ai", "s.jina.ai"] and required to use the https: protocol (server.ts:362-365). SSRF to internal services is impossible by construction.

If a future CodeQL update flags these sites again, the suppressions and allowlist check should be re-verified, not removed.

All third-party Actions are pinned to a commit SHA, not a tag, to prevent supply-chain attacks via a compromised tag update. The version comment is appended after the SHA for maintainer reference:

• actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 (v4.2.2)
• actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 (v4.4.0)
• actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 (v4.6.2)
• actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 (v4.3.0)
• softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda (v3.0.0)

When bumping any pinned action, look up the new SHA via gh api repos/<owner>/<repo>/git/refs/tags/<tag> and update both the SHA and the version comment. Dependabot's github-actions ecosystem entry in .github/dependabot.yml keeps the SHAs current.