Security · Posture
Security stated only as far as it is true.
This page describes what LeanLogix actually does to protect models, the data they are built from, and the evidence we sign. It does not claim a certification we have not earned. Where a control is a design decision you can inspect — in the weights, in the receipt, in the response headers — we say exactly what it is and how to check it.
What goes into the weights
Weight updates need an explicit evidence boundary.
LeanLogix does not currently expose a generic base-training path. The supported fork-candidate path applies a deny-by-default sensitive-source guard before it can create a non-routable candidate. That control describes inputs processed by LeanLogix; it does not certify an external training run or prove a physical deployment boundary.
Unsupported weight-update paths stay unavailable
Generic training and quantization execution are retired until authoritative base-model and dataset sources exist. The product does not turn an unverified upload or a UI selection into a runnable training job.
The fork guard is a minimum policy floor
The implemented fork guard partitions allowed and sensitive source classes before candidate creation. A release still needs attributable dataset evidence and independent review; the guard is not a universal claim about data handled outside this path.
Deployment-gated boundary control
The target per-fork deployment is an in-boundary, OpenAI-compatible endpoint where the weights do not leave the boundary to be served and no external per-token meter is required. Fork training currently seals a non-routable candidate only; every fork-serving request returns 503 until a real deployment attests the exact loaded weights. Base request-time serving is separate.
Evidence and signing
Signed evidence is issued only when its prerequisites hold.
The public decision-proof path signs canonical evidence with Ed25519 and can be checked independently. Release passports and governed serving receipts are implemented contracts, but they require matched signing authority, authenticated production state, and configured serving identity before they describe a real release or execution.
A release passport after authoritative approval
A candidate that satisfies exact source identity, local evaluation and policy, separation of duties, and matched signing authority can receive a Model Passport over its canonical bytes. Raw release evidence is an authenticated export; the public catalog exposes only a privacy-safe, server-verified summary.
Governed serving binds the run, not the conversation
When governed serving is configured and admitted, its contract emits a content-free receipt that binds release identity, backend identity, policy, and request shape without prompt or response text. This proves the recorded admission event; it does not attest exact loaded weights or physical execution location.
Separation of duties on release
The release-authority contract rejects self-approval and derives the candidate from an authoritative completed source job. This invariant is implemented and tested; production assurance still requires configured identities, live database policy, and an exercised two-actor workflow.
Application surface
The site itself is hardened, and you can check the headers.
Every response from this site carries a Content-Security-Policy with a bounded connect-source allowlist, HTTP Strict Transport Security, a frame-ancestors clickjacking deny, MIME-sniffing protection, and a restrictive Permissions-Policy. These are observable in the response headers — not a claim you have to take on trust.
Verifiable response headers
Content-Security-Policybounded script/style/connect sources; object-src noneStrict-Transport-Securitymax-age 2 years, includeSubDomains, preloadX-Frame-Options / frame-ancestorsDENY / 'none' — no clickjackingX-Content-Type-OptionsnosniffReferrer-Policystrict-origin-when-cross-originPermissions-Policycamera/geolocation off; microphone scoped to the in-page voice concierge
What we do not claim
The honest boundary of this page.
A security page that overstates is worse than none. So here is what we are not saying.
No certification we have not earned
We do not claim SOC 2, ISO 27001, or HIPAA certification. The controls above are real design decisions and process commitments; they are not a substitute for, or a claim of, a third-party audit we do not hold.
No unhackable or injection-proof model
Hardening measures defense-in-depth resistance behind a governance gate and reports residual attack-success per release. We do not claim a model cannot be attacked — we claim we measure it and publish our own numbers.
No security by adjective
The live public decision receipt is distinct from an authenticated release passport and from a serving receipt. We do not claim exact loaded-weight attestation, physical-boundary attestation, or a configured production workspace until each is independently exercised.
Responsible disclosure
Found something? Tell us directly.
If you believe you have found a security vulnerability in LeanLogix, report it privately to the address below before disclosing it publicly. Include enough detail to reproduce the issue. Maintainers will triage it through the private GitHub security process; no response-time or remediation-time commitment is currently published. We ask that you avoid privacy violations, data destruction, and service disruption while testing, and that you give us reasonable time to fix an issue before going public.
Security contact
security@leanlogix.ai