Project

Security Policy

Zolva is built for banks and fintechs; security reports get priority over everything else.

Reporting a vulnerability

Include:

• A description of the issue and the affected component (config loader, tool registry, bridge, orchestrator, channels, handover, CLI).
• Reproduction steps or a proof-of-concept.
• The version or commit you tested against.

You will get an acknowledgement within 72 hours and a remediation timeline within 7 days. We ask for coordinated disclosure: give us 90 days (or an agreed timeline) before publishing.

Scope

• Zolva is self-hosted: the runtime never sends data anywhere except the LLM provider the operator configures. Reports about provider-side handling are out of scope.
• Prompt-injection findings against the orchestrator's tool-result handling, guardrail bypasses, channel-payload validation, and secrets handling in the config loader are all firmly in scope.

Supported versions

Pre-1.0: only the latest release receives security fixes.

How the platform defends itself

The full threat model, mitigation by mitigation, lives in the documentation's security model. The short form:

• Tool results are data, never re-interpreted as instructions; never guardrails cannot be configured off.
• Per-agent tool and channel allowlists; Pydantic-validated I/O with extra="forbid".
• No secrets in config: the loader rejects anything credential-shaped that is not a ${ENV:VAR} reference.
• yaml.safe_load only; no eval, exec, or pickle anywhere.
• Sessions isolated per session_id and namespaced per channel; no cross-session context is ever assembled.
• Hash-chained audit log; edits, deletions, and reordering are detectable.
• Three runtime dependencies; bandit and pip-audit run in CI on every commit.

This page mirrors SECURITY.md in the repository; if they ever disagree, the repository file is authoritative.