Entroly handles source code, prompts, model responses, credentials passed to configured providers, and recoverable context artifacts. Security reports are treated as product-trust incidents.
Security fixes are released on the latest stable 1.0.x line. Users should run
the newest published patch because Entroly does not maintain parallel patch
branches for older releases.
| Release line | Security support |
|---|---|
Latest published 1.0.x |
Supported |
Earlier 1.0.x patches |
Upgrade required |
0.x and older |
Unsupported |
Runtime and platform details are maintained in SUPPORTED_VERSIONS.md.
Do not open a public issue for a suspected vulnerability.
Email fastrunner10090@gmail.com with the subject
[Entroly security] <short description>. Include, when available:
- the affected version, installation method, and operating system;
- a minimal reproduction or proof of concept;
- expected and observed behavior;
- potential impact and whether credentials or user data may be exposed;
- any suggested mitigation;
- whether you want public credit in the advisory.
Never include live provider keys, private source code, or other people's data. Use synthetic fixtures and redact logs whenever possible.
The project aims to acknowledge a complete report within 48 hours and provide an initial assessment within seven days. Resolution timing depends on severity, reproduction quality, and coordinated-disclosure needs. Reporters will receive updates when the assessment, mitigation, release, or disclosure status changes.
For a confirmed vulnerability, maintainers will:
- reproduce and scope the issue privately;
- prepare a minimal regression test and fix;
- review affected Python, Rust, WASM, npm, Docker, MCP, and integration surfaces;
- publish patched artifacts before publicizing exploit details;
- publish a GitHub Security Advisory with affected and fixed versions;
- credit the reporter when requested and appropriate.
- Entroly is local-first, but configured proxy/provider paths necessarily send selected request data to the provider chosen by the operator.
- Context Receipts and Context Commits may contain source material or exact recovery data. Protect them with the same access and retention policy as the source repository.
- Content addressing detects mutation; it does not prove operator identity unless an authenticated signing or attestation path is used.
- Remote model-registry discovery is opt-in. Local ranking, verification, and diagnostics must not introduce surprise remote calls.
- Fail-open optimization means an internal optimization error should preserve the original request. Security, authorization, path-safety, and explicit compliance gates remain fail-closed.
WITNESS/EICV output is advisory evidence, not a certification. False positives
and false negatives are possible, performance varies by domain, and independent
validation is required for medical, legal, financial, regulated, or
safety-critical uses. audit mode is the safest default when modifying an AI
response would be undesirable. Current benchmark artifacts and limitations live
under benchmarks/results/ and
docs/limitations.md.