One authority, fail closed
No enforcement point decides alone. Unavailable dependencies produce refusals, never silent permits.
Verity Command / Security
Security is the product, not a feature of it.
Verity Command is designed on the assumption that networks are contested, insiders exist and any single component can fail.
Security invariants
Record before effect
Nothing changes in the world until its decision record is committed, signed and time-stamped.
Recommend, authorize, execute
Three services, three credential sets. Compromising one does not grant the powers of another.
Customer-held roots of trust
Root keys are generated and held by the customer. The vendor holds no key that can read or authorize.
Secure engineering
- Protected sourceSigned commits, branch protection, code ownership and mandatory review on security-critical paths.
- Automated gatesStatic analysis, secret scanning, dependency policy and invariant tests block the pipeline on failure.
- Known compositionA software bill of materials accompanies every build.
- Verifiable deliveryReleases are signed so customers can verify exactly what they install.
Assurance
We state an assurance result only after an independent party has produced it, and we name that party and its scope when we do. We do not use certification or accreditation language before it is earned.
Customers and prospective partners can request our threat model and security architecture under a non-disclosure agreement.
Report a vulnerability
If you believe you have found a security issue in Verity Command or this website, write to . Our vulnerability disclosure policy explains scope and safe harbor.