Worthless exists to protect API keys, a vulnerability here has real consequences.

• Preferred: GitHub Private Vulnerability Reporting
• Alternative: Email security@wless.io

Solo maintainer, response time is bounded by real life. Acknowledgment, triage, fix, and coordinated disclosure are all handled on a best-effort basis, proportional to severity, with no committed timeframe. If a report sits without reply for a while, ping again or escalate publicly.

Vulnerabilities in the following areas are in scope:

• Crypto, key splitting, reconstruction, commitment scheme, zeroing
• Proxy, gate-before-reconstruct bypass, request smuggling, error leakage
• Storage, shard encryption at rest, repository access controls
• CLI, credential handling, shard exposure, command injection
• Installer, the curl -sSL https://worthless.sh | sh supply chain. Trust roots and what install.sh verifies today: docs/install-security.md.

• Denial of service against the self-hosted proxy (it's your infrastructure)
• Social engineering
• Attacks requiring physical access to the host machine
• Issues in dependencies (report upstream; I'll update promptly)

As an open-source project, you are encouraged to audit and test the code. Please ensure you:

• Only test against infrastructure and accounts that you own or have explicit permission to test against.
• Report vulnerabilities through the channels above before discussing them publicly, giving me time to patch the code.

English.

Your API key is split in two on the client using a format-preserving one-time pad. Shard A replaces the original key in your .env, it looks like a real key but is cryptographically useless alone. Shard B lives on the proxy, Fernet-encrypted at rest. Every request hits the rules engine before the key reconstructs: if a rule denies it (spend cap, rate limit, model not allowed), the key is not reconstructed and the request never leaves the proxy. Because the spend check estimates cost before each call, a single in-flight request can exceed a spend cap by up to the cost of one call before the next is denied.

Architectural invariants, known limitations, breach scenarios, forensic logging gaps, and residual risk: docs/security.md.

Contributor invariants (the SR-* rules enforced by CI): CONTRIBUTING-security.md.