lex-soft is the engine behind cross-organisation agent coordination and
evidence-gated settlement — it can gate the movement of money between
counterparties. Security reports are taken seriously.
Please report privately, not via a public issue:
- Email security@alpibru.com (or
alfonso@alpibru.com), or - Open a GitHub private security advisory on this repository.
Include what you found, how to reproduce it, and the impact. We aim to acknowledge within a few working days and to agree a disclosure timeline with you. Please give us reasonable time to fix before any public disclosure.
Only the current main is supported. Pin to a reviewed commit for production.
- Load-bearing dependencies are out of scope of this repo's guarantees. The
actual proof, spend-cap, and cryptographic logic live in
lex-trail,lex-guard, andlex-crypto. A signature-verification or spend-cap bug there would undercut guarantees this repo appears to provide. Those deserve their own review before production settlement. - Builds are not yet fully reproducible. Dependencies are declared as git refs; the flat layout plus unpinned transitive deps means a lockfile (pinning the whole closure) is required for true reproducibility, and that is an upstream tooling gap. CI verifies the toolchain download's checksum.
- Some routes assume an authenticating gateway in front. Onboarding and
discovery endpoints must be gated (signup token / proof-of-org) before being
exposed to the internet — see
FederationConfig. - Partner key binding is trust-on-first-use, not proof of identity. Binding
an Ed25519 key to an org requires signing a server-issued, single-use
challenge, and replacing an existing key additionally requires a signature
from the key being replaced. That proves possession of a key and
continuity of whoever bound it first. It does not prove the caller is
the real-world organisation whose name it claims: that needs a binding from
the org id to something externally verifiable — a domain serving
/.well-known/agent-key.json— and org ids here are opaque slugs, not domains. Until then, who may claim a new org name is governed only by the signup token, so treat that token as the org-namespace admission control it is.
Active remediation (from the 2026-07 audit) is tracked in the issue tracker: fail-closed verdicts, authenticated onboarding, dispatch-path revocation, indexed tenant scoping. Do not run this against real value until the before-deployment tier is complete.