Security-led, and honest about where we are.
Quayfold is pre-launch. The controls below are implemented in the code you can try today. We do not claim third-party certifications or attestations.
The request path and where each control sits.
Browser or API consumer
- Session cookie (httpOnly, SameSite)
- CSRF token header on writes
- No secrets in client storage
Transport and browser policy
- TLS and HSTS (over HTTPS)
- Content-Security-Policy with nonces
- Frame denial, no MIME sniffing
- Per-IP and per-account rate limits
Server-side enforcement
- Opaque session, SHA-256 at rest
- Origin and CSRF verification
- Role checks on every endpoint
- Strict schema validation
Storage and evidence
- Parameterised statements only
- argon2id credential hashes
- Hash-chained, append-only audit
- Verification on demand
Implemented in the product today.
Authentication
argon2id password hashing with memory-hard parameters. Opaque 256-bit session tokens, stored only as SHA-256 hashes, with idle and absolute expiry. Account lockout after repeated failures and equalised timing for unknown accounts.
Session and request integrity
httpOnly, SameSite cookies (Secure over HTTPS). Double-submit CSRF tokens plus Origin checking on every state-changing request. Session invalidation on password change and role change.
Authorisation
Role-based permissions evaluated on the server for every endpoint. The interface hides what you cannot do, but the API refuses it regardless. Four-eyes rule on approvals.
Input and data handling
Every endpoint validates input with strict schemas before any logic runs. All database access uses parameterised statements. CSV exports neutralise spreadsheet formula injection.
Audit and accountability
Append-only audit log where each entry includes the hash of the previous one. The verification badge on the Audit page recomputes the chain on demand.
Transport and browser hardening
Content-Security-Policy with per-request nonces, HSTS over HTTPS, frame denial, strict referrer policy, no MIME sniffing, and a locked-down permissions policy.
What is implemented, what is planned, and what is not claimed.
We would rather be precise than impressive. Customers with regulatory requirements should treat Quayfold as pre-assessment software.
| Control area | Status | Detail |
|---|---|---|
| Credential storage | Implemented | argon2id with unique salts; lockout after repeated failures. |
| Session management | Implemented | Opaque tokens stored hashed, idle and absolute expiry, rotation on password change. |
| Access control | Implemented | Four roles enforced in the API. Approvals require a second person. |
| Tamper evidence | Implemented | Hash-chained audit trail with a verification action in the console. |
| Single sign-on and SCIM | Planned | SAML or OIDC with directory provisioning, scoped with early-access customers. |
| Independent penetration test | Planned | To be completed before production tenants are onboarded; summary to be published. |
| SOC 2, ISO 27001 or similar | Not claimed | No third-party attestation or certification has been completed. None is implied. |
What is planned before production tenants are onboarded.
An independent penetration test, SSO with SCIM provisioning, per-tenant encryption keys, and a formal compliance programme scoped with early-access customers.
- Independent penetration test and published summary
- SSO (SAML / OIDC) and SCIM provisioning
- PostgreSQL with row-level tenant isolation
- Managed secrets and key rotation
- Rate limiting backed by a shared store
Found a vulnerability? Please report it through unitoneai.com with details and we will respond promptly.