Trust
How this is secured, and what is not certified yet.
Clyreon holds your company's judgment, including judgments about people, suppliers and candidates. Everything below is built and running today. What is not yet done is named.
What is not certified yet
At the top of the page, where it belongs.
Independent penetration testing and a completed SOC 2 report are scheduled before general availability and are not done today. There is no certificate to show you, and nothing on this page implies otherwise.
What is complete is everything below. These are properties of how the system is built rather than settings somebody switched on. What is still ahead is having an auditor confirm it.
The same statement is made in the security policy shipped with the product and in the guide handed to design partners. It is not phrased more optimistically anywhere.
Access control
Authority is granted explicitly, never inherited from being logged in.
Every action requires a permission granted explicitly to whoever is acting: record.open, judgment.record, record.seal, and so on. There is no implicit role inherited from having an account, and no implicit administrator who bypasses the check. The same check runs whether the request comes from the product interface, a webhook, or the API.
“Was this person allowed to do that at the time?” is answered by replaying the permission history to that day, not by checking who has access now. Grants and removals are themselves append-only.
SSO via OIDC and SCIM user provisioning are both supported.
Every request is authenticated and rate-limited before it reaches any business logic. Signup, login and password reset, which have no credential to count against, get a separate, stricter, IP-keyed budget specifically to slow credential stuffing.
Isolation between organisations
Enforced twice, independently, and one of the two is below the application.
One running process serves every organisation it has provisioned. Application code resolves organisation scope fresh on every request from the authenticated caller’s own membership, never from client input, and never cached for the life of a connection.
Postgres row-level security then enforces the same boundary a second time, at the database layer, under a restricted role that cannot see or write another organisation’s data even if application code had a bug that forgot to filter. A dedicated isolation test suite proves this holds when a query's own filter asks for another organisation’s data by name, and under concurrent requests from different organisations sharing one connection pool.
The privileged migration role that applies schema and bootstraps that restricted role is never present in the running server’s environment.
Self-hosting a physically separate deployment remains available where a compliance posture requires that stronger guarantee.
Data protection
Secrets, deliveries, and getting your data back out.
Connector credentials and webhook signing secrets are encrypted at rest with AES-256-GCM, using a separate key per secret, each wrapped by a master key supplied to the deployment. Never stored or logged in plain text.
Outbound event deliveries are HMAC-SHA256 signed against a per-subscription secret, so a receiver can cryptographically verify a delivery actually came from Clyreon.
A logical export of every ledger for your organisation, on demand, with integrity verification. This is your data, and leaving with it intact is always possible.
Evidence can be redacted once its own retention schedule expires, as a deliberate, logged administrative act. Decision Records themselves are never swept automatically. There is no background job quietly deleting history.
Auditability
Access is logged, not only change.
Reads, exports, denials and administrative actions append to their own ledger, which is itself append-only and hash-chained. A record that some people can quietly read without a trace is not a trustworthy record, and a refused write that leaves nothing behind is the signature of a compromised credential going unnoticed.
Exports are logged separately from reads on purpose: a record leaving the building is a materially different event, because it is the point after which Clyreon’s immutability guarantees stop applying to that copy.
Deployment
Deliberately small, and sized for the stage the company is at.
One process backed by a single Postgres database, serving every organisation it has provisioned. Not a queue, a cache or a search cluster. It is sized for the scale this architecture is honestly built for, rather than a placeholder for infrastructure that does not exist yet.
The API is REST, authenticated by a bearer API key, a session token or an OIDC token, and documented by a live OpenAPI document generated from the routes the server actually serves, so the documentation cannot drift from the API it describes.
Data residency, encryption key rotation policy, incident notification timelines and the sub-processor list are handled directly, case by case, during the design-partner agreement rather than asserted here.
Reporting a vulnerability
Where to send it, and when you will hear back.
Email security@clyreon.com with a description and, if possible, reproduction steps. Expect an acknowledgment within one business day. Please do not open a public issue for a security vulnerability.