We document what is complete and what is in progress. Transparency is the posture. If you are in enterprise procurement and need something not listed here, ask us directly.
Every internal deployment, security test, and engineering decision we run through our own evaluation pipeline. The artifacts are independently reviewable by any client or prospect on request. We do not ask you to trust our claims. We give you the record.
Security documentation that says "we follow best practices" is not security. Every control listed here is enforced at the infrastructure or code level. Not by process. Not by policy. By the system itself.
We do not list aspirational controls as complete. If it is in progress, it says in progress. If it is not started, it is not on this list.
| Control | Description | Status |
|---|---|---|
| Tenant separation | Shard-based isolation. Logical separation of tenant data. Physical isolation (dedicated infra per tenant) available for enterprise at additional cost. | Complete |
| Asymmetric KMS signing | KMS asymmetric artifact signing. Private key non-exportable, managed entirely within Google Cloud KMS. Key version reference included in every artifact for offline verification. | Complete |
| Append-only enforcement | Two-layer enforcement: Firestore rules plus application layer. HTTP 409 on post-close writes. | Complete |
| Fail-closed production | Write failures surface to caller. No silent unrecorded decisions. | Complete |
| API key hashing at rest | API keys are hashed before storage. Raw keys are never persisted. | Complete |
| CI security scanning | Automated security scanning on every commit via CI pipeline. | Complete |
| Rate limiting | Per-tenant rate limiting on all API endpoints. | Complete |
| Load testing | Production load tested. Results available on request. | Complete |
| Third-party penetration test | Independent security audit by external firm. Scheduled prior to enterprise deployment. | Prioritized |
| SOC 2 Type II | Full audit cycle planned. Targeted for active enterprise deployments. | Prioritized |
Every artifact we produce is signed using Google Cloud KMS asymmetric signing. The private key is non-exportable and remains inside KMS at all times. To verify the signature, you need only the public key; the artifact includes the key version reference needed to identify the signing key. No API access. No credentials. No trust in our infrastructure required.
This is what makes the artifact meaningful in a legal or regulatory context. The record does not depend on our word. It depends on the math.
Any modification to any entry in the artifact breaks the SHA-256 chain. Any modification to the artifact itself breaks the KMS signature. Both failures are detectable without our involvement.
# Verify a ProjectLedger artifact # No API access required. # Public key only. # 1. Download the artifact curl -o artifact.json \ https://ledger.projectledger.io/artifact/6VOIW4G # 2. Extract the signature cat artifact.json | jq -r .signature \ | base64 -d > signature.bin # 3. Extract the signed payload cat artifact.json | jq -r .payload \ > payload.json # 4. Verify with public key openssl dgst -sha256 -verify \ projectledger-public.pem \ -signature signature.bin \ payload.json # Verified OK
Overclaiming security is a form of deception. The artifact proves specific things. It does not prove everything. Any vendor who claims otherwise is lying to you.
The list on the right is what you can take to a regulator, a legal team, or an auditor and stand behind. The list of what we do not claim is just as important.
If you are in procurement and need something not covered here: a specific control, a questionnaire, or a call with our engineering team, reach out. We will answer directly and in writing.
Contact Security Team